home *** CD-ROM | disk | FTP | other *** search
- Implementation issues:
-
- * FriBidiEnv type should be defined that is to hold all global variables
- and should be passed as environment to all fribidi functions.
-
- * Add const keywords all over the source.
-
- * with --without-charsets, fribidi char set converters use iconv internally.
-
- * Update CapRTL with new Unicode reference version.
-
- * Revise Reorder api, in fribidi_main.c reorder after link break.
-
- * Add an option to fribidi_main.c to assume two consecutive returns as
- paragraph separators.
-
- * Change fribidi_main.c to act like 'bidiv' if argv[0] == "bidiv".
-
- * Fix iconv problem: Check for old iconvs (without wchar_t, without
- byteorder UTF-32 or UCS-4 types).
-
- * When there is no glibc, libiconv should be linked when --without-charset
- is enabled.
-
- * Design better apis to do reorder based on available levels, remove
- explicit marks then calculate position maps, ....
-
- * Revise fribidi_util.c, add some functions, update other to support explicit
- marks, and too many embedding levels, eg. fribidi_map_range.
-
- * Charset converters and fribidi_analyse change API to allocate mem if
- NULL is passed to them.
-
- BiDi algorithms issues:
-
- General issues:
-
- * Better documentation.
-
- * Write notes and a reference implementation for the following interactions
- with fribidi:
-
- - Terminal editing with cursor key interaction, e.g. through curses.
- No mouse or cut and paste interaction.
-
- - Like above (with fixed width fonts?) but in an GUI environment
- where the mouse may be used to position the cursor.
-
- - Like above but with the ability to do a mouse selection. At least
- in logical mode, possibly in visual mode.
-
- - Like above but with proportional fonts.
-
- - Like above with proportional fonts and character attributes.
-
- - Like above but with kerning between characters.
-
- * Write a description of the needed steps to convert a LTR editor into a
- BiDi aware editor.
-
- * Make interfaces to other scripting languages if there is any interest.
-
- * Consider the implications of a minimal incremental algorithm for
- adding a single character.
-
- * Add handling of precomposed and presentation unicode chars when converting
- to 8-bit encodings (breaking into several chars, or better match)
-
- * Persian 8-bit encoding ISIRI-3342 has the notion of strong typed chars like
- spaces etc (all the characters in the range 0x00-0x7f are strongly typed
- left-to-right, and sometimes have duplicates in 0x80-0xff as a strongly
- typed right-to-left version. several chars in the range 0xa0-0xbf have
- exact unicode counterparts; but others (and all in the range 0x80-0x9f,
- and 0xff) have not; so how should that be handled when converting to
- unicode to preserve at best the direction information?
-